Method and system for virtual on-demand recovery for real-time, continuous data protection

ABSTRACT

A data management system or “DMS” provides an automated, continuous, real-time, substantially no downtime data protection service to one or more data sources associated with a set of application host servers. To facilitate the data protection service, a host driver embedded in an application server captures real-time data transactions, preferably in the form of an event journal that is provided to other DMS components. The driver functions to translate traditional file/database/block I/O and the like into a continuous, application-aware, output data stream. The host driver includes an event processor. When an authorized user determines that a primary copy of the data in the host server has become incorrect or corrupted, the event processor can perform a recovery operation to an entire data source or a subset of the data source using former point-in-time data in the DMS. The recovery operation may have two phases. First, the structure of the host data in primary storage is recovered to the intended recovering point-in-time. Thereafter, the actual data itself is recovered. The event processor enables such data recovery in an on-demand manner, in that it allows recovery to happen simultaneously while an application accesses and updates the recovering data.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application is a continuation of U.S. patent applicationSer. No. 11/185,313, filed on Jul. 20, 2005 now U.S. Pat. No. 7,788,521.U.S. patent application Ser. No. 11/185,313 is incorporated herein byreference.

This application is related to commonly-owned applications:

Ser. No. 10/841,398, filed May 7, 2004, and titled “METHOD AND SYSTEMFOR AUTOMATED, NO DOWNTIME, REAL-TIME, CONTINUOUS DATA PROTECTION.”

Ser. No. 10/842,286, filed May 10, 2004, and titled “METHOD AND SYSTEMFOR REAL-TIME EVENT JOURNALING TO PROVIDE ENTERPRISE DATA SERVICES.”

Ser. No. 10/863,117, filed Jun. 8, 2004, and titled “METHOD AND SYSTEMFOR NO DOWNTIME, REAL-TIME, CONTINUOUS DATA PROTECTION.”

Ser. No. 10/862,971, filed Jun. 8, 2004, and titled “METHOD AND SYSTEMFOR NO DOWNTIME, RESYNCHRONIZATION FOR REAL-TIME, CONTINUOUS DATAPROTECTION.”

BACKGROUND OF THE INVENTION

1. Technical Field

The present invention relates generally to enterprise data protection.

2. Background of the Related Art

A critical information technology (IT) problem is how tocost-effectively deliver network wide data protection and rapid datarecovery. In 2002, for example, companies spent an estimated $50Bworldwide managing data backup/restore and an estimated $30B in systemdowntime costs. The “code red” virus alone cost an estimated $2.8B indowntime, data loss, and recovery. The reason for these staggering costsis simple-traditional schedule based tape and in-storage data protectionand recovery approaches can no longer keep pace with rapid data growth,geographically distributed operations, and the real time requirements of24×7×365 enterprise data centers.

Traditionally, system managers have used tape backup devices on aperiodic basis to store application and system data, or to generatevolume snapshots of a primary storage. Conventional tape backup toolstypically extract data from an application, dump the data into one ormore tapes, and then make a catalog that associates the data and theparticular tapes, as well as offset data within a tape. Conventionalvolume snapshot tools provide the ability to acquire a “snapshot” of thecontents of an entire hard disk at a particular time and then store thisfor later use, e.g., reintroduction onto the disk (or onto a new disk)should the computer fail. The application data can be re-introduced tothe application at a later time in the event of a failure event. Theproblems with these backup approaches are well known and appreciated.First, changes in data occurring after a backup or snapshot is taken arealways at risk and may be lost. Second, tape backup requires that thehost application be shutdown or be put into a backup mode for a longtime period until the complete data set is copied to tape. Third, as thedata size grows, the bandwidth required to offload data repeatedly andthe attendant storage required to store the complete snapshots canbecome impractical quickly. Further, during a “hot” snapshot criticaldata can change, which may result in an incomplete update being captured(e.g., only one portion of a transaction) such that, when reintroduced,the data is not fully consistent. Most importantly, storage basedsnapshot does not capture fine grain application data and, therefore, itcannot recover fine grain application data objects without reintroducing(i.e. recovering) the entire backup volume to a new application computerserver to extract the fine grain data object.

Data recovery on a conventional data protection system is a tedious andtime consuming operation. It involves first shutting down a host server,and then selecting a version of the data history. That selected versionof the data history must then be copied back to the host server, andthen the host server must be re-started. All of these steps are manuallydriven. After a period of time, the conventional data protection systemmust then perform a backup on the changed data. As these separate anddistinct processes and systems are carried out, there are significantperiods of application downtime. Stated another way, with the currentstate of the art, the processes of initial data upload, scheduled orcontinuous backup, data resynchronization, and data recovery, areseparate and distinct, include many manual steps, and involve differentand uncoordinated systems, processes and operations.

BRIEF SUMMARY OF THE INVENTION

A data management system or “DMS” provides an automated, continuous,real-time, substantially no downtime data protection service to one ormore data sources associated with a set of application host servers. Thedata management system typically comprises one or more regions, witheach region having one or more clusters. A given cluster has one or morenodes that share storage. To facilitate the data protection service, ahost driver embedded in an application server captures real-time datatransactions, preferably in the form of an event journal that isprovided to a DMS cluster. The driver functions to translate traditionalfile/database/block I/O and the like into a continuous,application-aware, output data stream. The host driver includes an eventprocessor that provides the data protection service. In particular, thedata protection is provided to a given data source in the host server bytaking advantage of the continuous, real-time data that the host driveris capturing and providing to other DMS components.

When an authorized user determines that a primary copy of the data inthe host server has become incorrect, corrupted or lost, the eventprocessor can perform a recovery operation to an entire data source or asubset of the data source using former real-time data history in theDMS. The recovery operation preferably has two (2) distinct phases.First, the structure of the host data in primary storage is recovered tothe intended recovering point-in-time. Thereafter, the actual dataitself is recovered. The event processor enables such data recovery inan on-demand manner, in that it allows recovery to happen simultaneouslywhile an application accesses and updates the recovering data. When datarecovery is completed, the state of the data across DMS is synchronized,and the corruption at the host is fixed. The event processor thenreturns to its regular back-up function.

According to the invention, data recovery is applied on an existing datasource. For example, a data source X in a host is protected and itshistory is captured in a DMS data source Y. If an administrator wants torecover a subset of the full data source X to a point-in-time in thepast, he or she initiates a data recovery, preferably via a graphicaluser interface (GUI). In a representative embodiment, the administrator(or other authorized user) initiates the recovery by issuing a recoverycommand to a DMS data source object, which then forwards the command toa data agent in the host driver. The data source object first adjustsits current state by moving the state in the past to a current state.The data agent then pulls the most current state from the data source.During data recovery, the data agent preferably continues to allow anapplication to update the data in primary storage associated with thatapplication. If the data that an application tries to access is not yetrecovered, the data agent immediately recovers the data requested. Afterdata recovery is completed, the data agent switches its mode back toreal-time data protection.

The foregoing has outlined some of the more pertinent features of theinvention. These features should be construed to be merely illustrative.Many other beneficial results can be attained by applying the disclosedinvention in a different manner or by modifying the invention as will bedescribed.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention and theadvantages thereof, reference is now made to the following descriptionstaken in conjunction with the accompanying drawings, in which:

FIG. 1 is an illustrative enterprise network in which the presentinvention may be deployed;

FIG. 2 is an illustration of a general data management system (DMS) ofthe present invention;

FIG. 3 is an illustration of a representative DMS network according toone embodiment of the present invention;

FIG. 4 illustrates how a data management system may be used to provideone or more data services according to the present invention;

FIG. 5 is a representative host driver according to a preferredembodiment of the present invention having an I/O filter and one or moredata agents;

FIG. 6 illustrates the host driver architecture in a more generalfashion; and

FIG. 7 illustrates a preferred implementation of an event processorfinite state machine (FSM) that provides automated, real-time,continuous, zero downtime data protection service;

FIG. 8 is a simplified diagram illustrating how the event processoroperates in the initial upload and resynchronization states;

FIG. 9 is a flowchart illustrating the steps performed by the eventprocessor during the initial upload and resynchronization states;

FIG. 10 is a flowchart illustrating how the event processor handlesinternal events, which is a step of the flowchart in FIG. 9;

FIG. 11 is a flowchart illustrating how the event processor handles I/Oevents, which is a step of the flowchart in FIG. 9;

FIG. 12 is a flowchart illustrating how the event processor handlesnetwork, system, application and database events, which is a step of theflowchart in FIG. 9;

FIG. 13 is a flowchart illustrating how the event processor handlesprotocol transport events, which is a step of the flowchart in FIG. 9;

FIG. 14 is a flowchart illustrating how the event processor operates inthe recovering-frame state;

FIG. 15 is a flowchart illustrating how the event processor operates inthe recovering state;

FIG. 16 is a flowchart illustrating how the event processor handles I/Oevents during the recovering state; and

FIG. 17 is a flowchart illustrating the event processor handles protocoltransport events in the recovering state.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

FIG. 1 illustrates a representative enterprise 100 in which the presentinvention may be implemented. This architecture is meant to be taken byway of illustration and not to limit the applicability of the presentinvention. In this illustrative example, the enterprise 100 comprises aprimary data tier 102 and a secondary data tier 104 distributed overIP-based wide area networks 106 and 108. Wide area network 106interconnects two primary data centers 110 and 112, and wide areanetwork 108 interconnects a regional or satellite office 114 to the restof the enterprise. The primary data tier 102 comprises applicationservers 116 running various applications such as databases, emailservers, file servers, and the like, together with associated primarystorage 118 (e.g., direct attached storage (DAS), network attachedstorage (NAS), storage area network (SAN)). The secondary data tier 104typically comprises one or more data management server nodes, andsecondary storage 120, which may be DAS, NAS, and SAN. The secondarystorage may be serial ATA interconnection through SCSI, Fibre Channel(FC or the like), or iSCSI. The data management server nodes create alogical layer that offers object virtualization and protected datastorage. The secondary data tier is interconnected to the primary datatier, preferably through one or more host drivers (as described below)to provide real-time data services. Preferably, and as described below,the real-time data services are provided through a given I/O protocolfor data transfer. Data management policies 126 are implemented acrossthe secondary storage in a well-known manner. A similar architecture isprovided in data center 112. In this example, the regional office 114does not have its own secondary storage, but relies instead on thefacilities in the primary data centers.

As illustrated, a “host driver”128 is associated with one or more of theapplication(s) running in the application servers 116 to transparentlyand efficiently capture the real-time, continuous history of all (orsubstantially all) transactions and changes to data associated with suchapplication(s) across the enterprise network. As will be describedbelow, the present invention facilitates real-time, so-called“application aware” protection, with substantially no data loss, toprovide continuous data protection and other data services including,without limitation, data distribution, data replication, data copy, dataaccess, and the like. In operation, a given host driver 128 interceptsdata events between an application and its primary data storage, and itmay also receive data and application events directly from theapplication and database. In a representative embodiment, the hostdriver 128 is embedded in the host application server 116 where theapplication resides; alternatively, the host driver is embedded in thenetwork on the application data path. By intercepting data through theapplication, fine grain (but opaque) data is captured to facilitate thedata service(s). To this end, and as also illustrated in FIG. 1, each ofthe primary data centers includes a set of one or more data managementservers 130 a-n that cooperate with the host drivers 128 to facilitatethe data services. In this illustrative example, the data center 110supports a first core region 130, and the data center 112 supports asecond core region 132. A given data management server 130 isimplemented using commodity hardware and software (e.g., an Intelprocessor-based blade server running Linux operating system, or thelike) and having associated disk storage and memory. Generalizing, thehost drivers 128 and data management servers 130 comprise a datamanagement system (DMS) that provides potentially global data servicesacross the enterprise.

FIG. 2 illustrates a preferred hierarchical structure of a datamanagement system 200. As illustrated, the data management system 200comprises one or more regions 202 a-n, with each region 202 comprisingone or more clusters 204 a-n. A given cluster 204 includes one or morenodes 206 a-n and a shared storage 208 shared by the nodes 206 withinthe cluster 204. A given node 206 is a data management server asdescribed above with respect to FIG. 1. Within a DMS cluster 204,preferably all the nodes 206 perform parallel access to the data in theshared storage 208. Preferably, the nodes 206 are hot swappable toenable new nodes to be added and existing nodes to be removed withoutcausing cluster downtime. Preferably, a cluster is a tightly-coupled,share everything grouping of nodes. At a higher level, the DMS is aloosely-coupled share nothing grouping of DMS clusters. Preferably, allDMS clusters have shared knowledge of the entire network, and allclusters preferably share partial or summary information about the datathat they possess. Network connections (e.g., sessions) to one DMS nodein a DMS cluster may be re-directed to another DMS node in anothercluster when data is not present in the first DMS cluster but may bepresent in the second DMS cluster. Also, new DMS clusters may be addedto the DMS cloud without interfering with the operation of the existingDMS clusters. When a DMS cluster fails, its data may be accessed inanother cluster transparently, and its data service responsibility maybe passed on to another DMS cluster.

FIG. 3 illustrates the data management system (DMS) as a network (ineffect, a wide area network “cloud”) of peer-to-peer DMS service nodes.As discussed above with respect to FIG. 2, the DMS cloud 300 typicallycomprises one or more DMS regions, with each region comprising one ormore DMS “clusters.” In the illustrative embodiment of FIG. 3, typicallythere are two different types of DMS regions, in this example an “edge”region 306 and a “core” region 308. This nomenclature is not to be takento limit the invention, of course. As illustrated in FIG. 1, an edgeregion 306 typically is a smaller office or data center where the amountof data hosted is limited and/or where a single node DMS cluster issufficient to provide necessary data services. Typically, core regions308 are medium or large size data centers where one or more multi-nodeclusters are required or desired to provide the necessary data services.The DMS preferably also includes one or more management gateways 310 forcontrolling the system. As seen in FIG. 3, conceptually the DMS can bevisualized as a set of data sources 312. A data source is arepresentation of a related group of fine grain data. For example, adata source may be a directory of files and subdirectory, or it may be adatabase, or a combination of both. A data source 312 inside a DMScluster captures a range of history and continuous changes of, forexample, an external data source in a host server. A data source mayreside in one cluster, and it may replicate to other clusters or regionsbased on subscription rules. If a data source exists in the storage of aDMS cluster, preferably it can be accessed through any one of the DMSnodes in that cluster. If a data source does not exist in a DMS cluster,then the requesting session may be redirected to another DMS clusterthat has the data; alternatively, the current DMS cluster may perform anon-demand replication to bring in the data.

Referring now to FIG. 4, an illustrative DMS network 400 provides a widerange of data services to data sources associated with a set ofapplication host servers. As noted above, and as will be described inmore detail below, the DMS host driver 402 embedded in an applicationserver 404 connects the application and its data to the DMS cluster. Inthis manner, the DMS host drivers can be considered as an extension ofthe DMS cloud reaching to the data of the application servers. Asillustrated in FIG. 4, the DMS network offers a wide range of dataservices that include, by way of example only: data protection (andrecovery), disaster recovery (data distribution and data replication),data copy, and data query and access. The data services and, inparticular, data protection and disaster recovery, preferably are streambased data services where meaningful application and data events areforwarded from one end point to another end point continuously as astream. More generally, a stream-based data service is a service thatinvolves two end points sending a stream of real-time application anddata events. For data protection, this means streaming data from a datasource (e.g., an external host server) into a DMS cluster, where thedata source and its entire history can be captured and protected. Datadistribution refers to streaming a data source from one DMS cluster intoanother DMS cluster, while data replication refers to streaming a datasource from a DMS cluster to another external host server. Preferably,both data distribution and data replication are real-time continuousmovement of a data source from one location to another to prepare fordisaster recovery. Data replication differs from data distribution inthat, in the latter case, the data source is replicated within the DMSnetwork where the history of the data source is maintained. Datareplication typically is host based replication, where the continuousevents and changes are applied to the host data such that the data isoverwritten by the latest events; therefore, the history is lost. Datacopy is a data access service where a consistent data source (or part ofa data source) at any point-in-time can be constructed and retrieved.This data service allows data of the most current point-in-time, or aspecific point-in-time in the past, to be retrieved when the data is ina consistent state. These data services are merely representative.

The DMS provides these and other data services in real-time with dataand application awareness to ensure continuous application dataconsistency and to allow for fine grain data access and recovery. Tooffer such application and data aware services, the DMS has thecapability to capture fine grain and consistent data. As will beillustrated and described, a given DMS host driver uses an I/O filter tointercept data events between an application and its primary datastorage. The host driver also receives data and application eventsdirectly from the application and database.

Referring now to FIG. 5, an illustrative embodiment is shown of a DMShost driver 500. As noted above, the host driver 500 may be embedded inthe host server where the application resides, or in the network on theapplication data path. By capturing data through the application, finegrain data is captured along with application events, thereby enablingthe DMS cluster to provide application aware data services in a mannerthat has not been possible in the prior art.

In this embodiment, a host server embedded host driver is used forillustrating the driver behavior. In particular, the host driver 500 ina host server connects to one of the DMS nodes in a DMS cluster (in aDMS region) to perform or facilitate a data service. The host driverpreferably includes two logical subsystems, namely, an I/O filter 502,and at least one data agent 504. An illustrative data agent 504preferably includes one or more modules, namely, an application module506, a database module 508, an I/O module 510, and an event processor orevent processing engine 512. The application module 506 is configuredwith an application 514, one or more network devices and/or the hostsystem itself to receive application level events 516. These eventsinclude, without limitation, entry or deletion of some critical data,installation or upgrade of application software or the operating system,a system alert, detecting of a virus, an administrator generatedcheckpoint, and so on. One or more application events are queued forprocessing into an event queue 518 inside or otherwise associated withthe data agent. The event processor 512 over time may instruct theapplication module 506 to re-configure with its event source to capturedifferent application level events.

If an application saves its data into a database, then a database module508 is available for use. The database module 508 preferably registerswith a database 520 to obtain notifications from a database. The module508 also may integrate with the database 520 through one or moredatabase triggers, or it may also instruct the database 520 to generatea checkpoint 522. The database module 508 also may lock the database 520(or issue a specific API) to force a database manager (not shown) toflush out its data from memory to disk, thereby generating a consistentdisk image (a binary table checkpoint). This process of locking adatabase is also known as “quiescing” the database. An alternative toquiescing a database is to set the database into a warm backup mode.After a consistent image is generated, the database module 508 thenlifts a lock to release the database from its quiescent state. Thedatabase events preferably are also queued for processing into the eventqueue 518. Generalizing, database events include, without limitation, adatabase checkpoint, specific database requests (such as schema changesor other requests), access failure, and so on. As with applicationmodule, the event processor 512 may be used to re-configure the eventsthat will be captured by the database module.

The I/O module 510 instructs the I/O filter 502 to capture a set of oneor more I/O events that are of interest to the data agent. For example,a given I/O module 510 may control the filter to capture I/O eventssynchronously, or the module 510 may control the filter to only captureseveral successful post I/O events. When the I/O module 510 receives I/Oevents 524, it forwards the I/O events to the event queue 518 forprocessing. The event processor 512 may also be used to re-configure theI/O module 510 and, thus, the I/O filter 502.

The event processor 512 functions to generate an application aware,real-time event journal (in effect, a continuous stream) for use by oneor more DMS nodes to provide one or more data services. Applicationaware event journaling is a technique to create real-time data captureso that, among other things, consistent data checkpoints of anapplication can be identified and metadata can be extracted. Forexample, application awareness is the ability to distinguish a file froma directory, a journal file from a control or binary raw data file, orto know how a file or a directory object is modified by a givenapplication. Thus, when protecting a general purpose file server, anapplication aware solution is capable of distinguishing a file from adirectory, and of identifying a consistent file checkpoint (e.g.,zero-buffered write, flush or close events), and of interpreting andcapturing file system object attributes such as an access control list.By interpreting file system attributes, an application aware dataprotection may ignore activities applied to a temporary file. Anotherexample of application awareness is the ability to identify a group ofrelated files, directories or raw volumes that belong to a givenapplication. Thus, when protecting a database with an application awaresolution, the solution is capable of identifying the group of volumes ordirectories and files that make up a given database, of extracting thename of the database, and of distinguishing journal files from binarytable files and control files. It also knows, for example, that thestate of the database journal may be more current than the state of thebinary tables of the database in primary storage during runtime. Theseare just representative examples, of course. In general, applicationaware event journaling tracks granular application consistentcheckpoints; thus, when used in conjunction with data protection, theevent journal is useful in reconstructing an application data state to aconsistent point-in-time in the past, and it also capable of retrievinga granular object in the past without having to recover an entire datavolume. Further details of the event journaling technique are describedin commonly-owned, co-pending application Ser. No. 10/842,286, filed May10, 2004, and titled “METHOD AND SYSTEM FOR REAL-TIME EVENT JOURNALINGTO PROVIDE ENTERPRISE DATA SERVICES.” The subject matter of thatapplication is incorporated herein by reference.

Referring now to FIG. 6, the host driver architecture is shown in a moregeneralized fashion. In this drawing, the host driver 600 comprises anI/O filter 602, a control agent 604, and one or more data agents 606.The control agent 604 receives commands from a DMS core 608, which mayinclude a host object 610 and one or more data source objects 612 a-n,and it controls the behavior of the one or more data agents 606.Preferably, each data agent 606 manages one data source for one dataservice. For example, data agent 1 may be protecting directory “dir1,”data agent 2 may be copying file “foo.html” into the host, and dataagent 3 may be protecting a database on the host. These are merelyrepresentative data service examples, of course. Each data agenttypically will have the modules and architecture described above andillustrative in FIG. 5. Given data agents, of course, may share one ormore modules depending on the actual implementation. In operation, thedata agents register as needed with the I/O filter 602, the database 614and/or the application 616 to receive (as the case may be): I/O eventsfrom the I/O filter, database events from the database, and/orapplication events from the application, the operating system and other(e.g., network) devices. Additional internal events or otherprotocol-specific information may also be inserted into the event queue618 and dispatched to a given data agent for processing. The output ofthe event processor in each data agent comprises a part of the eventjournal.

As also indicated in FIG. 6, preferably the host driver communicateswith the DMS core using an extensible data management protocol (XDMP)618 that is marshaled and un-marshaled through a device driver kit(DDK). More generally, the host driver communicates with the DMS coreusing any convenient message transport protocol. As will be described,given XDMP events may also be inserted into the event queue andprocessed by the event processor.

FIG. 7 illustrates a preferred embodiment of the invention, wherein agiven event processor in a given host driver provides a data protectionservice by implementing a finite state machine 700. Details of thefinite state machine are described in commonly-owned, co-pendingapplication Ser. No. 10/841,398, filed May 7, 2004, and titled “METHODAND SYSTEM FOR AUTOMATED, NO DOWNTIME, REAL-TIME, CONTINUOUS DATAPROTECTION.” The subject matter of that application is incorporatedherein by reference. The behavior of the event processor depends on whatstate it is at, and this behavior preferably is described in an eventprocessor data protection state table. The “state” of the eventprocessor preferably is driven by a given “incident” (or event) asdescribed in an event processor data protection incident table.Generally, when a given incident occurs, the state of the eventprocessor may change. The change from one state to another is sometimesreferred to as a transition. One of ordinary skill in the art willappreciate that FIG. 7 illustrates a data protection state transitiondiagram of the given event processor. In particular, it shows anillustrative data protection cycle as the FSM 700. At each state, asrepresented by an oval, an incident, as represented by an arrow, may ormay not drive the event processor into another state. The tail of anincident arrow connects to a prior state (i.e., branches out of a priorstate), and the head of an incident arrow connects to a next state. Ifan incident listed in the incident table does not branch out from astate, then it is invalid for (i.e., it cannot occur in) that state. Forexample, it is not possible for a “Done-Upload” incident to occur in the“UBlackout” state.

With reference now to FIGS. 6-7, the data protection service isinitiated on a data source in a host server as follows. As illustratedin FIG. 6, it is assumed that a control agent 604 has created a dataagent 606 having an event processor that outputs the event journal datastream, as has been described. As this point, the event processor in thedata agent 606 is transitioned to a first state, which is called“Initial-Upload” for illustrative purposes. During the “Initial-Upload”state 702, the event processor self-generates upload events, and it alsoreceives other raw events from its associated event queue. The eventprocessor simultaneously uploads the initial baseline data source, andit backs up the on-going changes from the application. Preferably, onlychange events for data already uploaded are sent to the DMS. The eventprocessor also manages data that is dirty or out-of-sync, as indicatedin a given data structure. In particular, a representative datastructure is a “sorted” source tree, which is a list (sorted using anappropriate sort technique) that includes, for example, an entry perdata item. The list preferably also includes an indicator or flagspecifying whether a given data item is uploaded or not, as well aswhether the item is in- (or out-of) sync with the data in the DMS.Additional information may be included in the sorted source tree, aswill be described in more detail below. As will be seen, the eventprocessor performs resynchronization on the items that are out-of-sync.As indicated in FIG. 7, a “Reboot” incident that occurs when the statemachine is in state 702 does not change the state of the eventprocessor; rather, the event processor simply continues processing fromwhere it left off. In contrast, a “Blackout” incident transitions theevent processor to a state 704 called (for illustration only)“UBlackout.” This is a blackout state that occurs as the event processoruploads the initial baseline data source, or as the event processor isbacking up the on-going changes from the application. The state 704changes back to the “Initial-Upload” state 702 when a so-called“Reconnected” incident occurs.

When upload is completed and all the data is in synchronized with thedata in the DMS, the event processor generates a “Done-upload” incident,which causes the event processor to move to a new state 706. This newstate is called “Regular-backup” for illustrative purposes. During theregular backup state 706, the event processor processes all the rawevents from the event queue, and it generates a meaningful checkpointreal time event journal stream to the DMS for maintaining the datahistory. This operation has been described above. As illustrated in thestate transition diagram, the event processor exits its regular backupstate 706 under one of three (3) conditions: a blackout incident, areboot incident, or a begin recovery incident. Thus, if during regularbackup a “Blackout” incident occurs, the state of the event processortransitions from state 706 to a new state 708, which is called“PBlackout” for illustration purposes. This is a blackout state thatoccurs during regular backup. If, however, during regular backup, a“Reboot” incident occurs, the event processor transitions to a differentstate 710, which is called “Upward-Resync” for illustrative purposes.The upward resynchronization state 710 is also reached from state 708upon a Reconnected incident during the latter state. Upwardresynchronization is a state that is entered when there is a suspicionthat the state of the data in the host is out-of-sync with the state ofthe most current data in the DMS. For this transition, it should also beknown that the data in the host server is not corrupted. Thus, atransition from state 706 to state 710 occurs because, after “Reboot,”the event processor does not know if the data state of the host isidentical with the state of the data in DMS. During the “Upward-Resync”710 state, whether the state is reached from state 706 or state 708, theevent processor synchronizes the state of the host data to the state ofthe DMS data (in other words, to bring the DMS data to the same state asthe host data). During this time, update events (to the alreadysynchronized data items) are continuously forwarded to the DMS as a realtime event stream. When the resynchronization is completed, the datastate at both the host and the DMS are identical, and thus a“Done-Resync” incident is generated. This incident transitions the eventprocessor back to the “Regular-backup” state 706. Alternatively, withthe event processor in the Upward-Resync state 710, a “Begin-Recovery”incident transitions the event processor to yet another new state 712,which is referred to “Recovering-frame” for illustration purposes.

In particular, once a baseline data is uploaded to the DMS, data historyis streamed into the DMS continuously, preferably as a real time eventjournal. An authorized user can invoke a recovery at any of the stateswhen the host server is connected to the DMS core, namely, during the“Regular-backup” and “Upward-resync” states 706 and 710. If theauthorized user does so, a “Begin-recovery” incident occurs, whichdrives the event processor state to the “Recovering-frame” state 712.

During the “Recovering-frame” state 712, the event processorreconstructs the sorted source tree, which (as noted above) containsstructural information of the data to be recovered. During state 712,and depending on the underlying data, the application may or may not beable to access the data. Once the data structure is recovered, a“Done-Recovering-Frame” incident is generated, which then transitionsthe event processor to a new state 714, referred to as “Recovering” forillustration purposes. Before the data structure is recovered, incidentssuch as “Blackout,” “Reconnected,” and “Reboot” do not change the stateof the event processor. During the “Recovering” state 714, the eventprocessor recovers the actual data from the DMS, preferably a data pointat a time. It also recovers data as an application access requestarrives to enable the application to continuing running. During state714, application update events are streamed to the DMS so that historyis continued to be maintained, even as the event processor is recoveringthe data in the host. When data recovery is completed, once again thestate of the data (at both ends of the stream) is synchronized, and thecorruption at the host is fixed. Thus, a so-called “Done-recovered”incident is generated, and the event processor transitions back to the“Regular-backup” state 706.

During the “UBlackout” or the “PBlackout” states (704 or 708), the eventprocessor marks the updated data item as dirty or out-of-sync in itssorted source tree.

Processing continues in a cycle (theoretically without end), with theevent processor transitioning from state-to-state as given incidents (asdescribed above) occur. The above described incidents, of course, aremerely representative.

Although not indicated in the state transition diagram (FIG. 7), a“termination” incident may be introduced to terminate the dataprotection service at a given state. In particular, a terminationincident may apply to a given state, or more generally, to any givenstate, in which latter case the event processor is transitioned (fromits then-current state) to a terminated state. This releases the dataagent and its event processor from further provision of the dataprotection service.

Further Details of the Initial Upload and Upward-Resync States

FIG. 8 illustrates the event processor behavior during respective uploadand upward-resynchronization states (702 and 710, respectively, in FIG.7) as part of the data protection service. As described above, theupload state creates baseline data. Preferably, the upload is a streamof granular application-aware data chunks that are attached to uploadevents. During this upload phase, the application does not have to beshutdown, which is highly advantageous. Simultaneously, while thebaseline is uploading and as the application updates the data on thehost, checkpoint granular data, metadata, and data events arecontinuously streamed into the DMS core, in real-time. Moreover, and aswill be described below, the update events for the data that are notalready uploaded preferably are dropped so that only the update eventsfor data already uploaded are streamed to the DMS.

As illustrated, the event processor 800 includes the event processorlogic 802 that has been previously described. Processor 800 also hasassociated therewith a given data structure 804, preferably a sortedsource tree. A sorted source tree is a list, which may be sorted usingany convenient sorting technique, and it is used to manage the handlingof data during the upload and/or upward-resync states. In an illustratedembodiment, the sorted source tree is a directory sort list, withdirectories and their associated files sorted in a depth-first manner asillustrated schematically at reference numeral 805. Preferably, the listincludes one or more one attributes per data item. A given attribute mayhave an associated flag, which indicates a setting for the attribute.Thus, for example, representative attributes include: data path, datastate, dirty, sent count, to be uploaded, to be recovered, and databitmap. The “data path” attribute typically identifies the path name(e.g., c:\mydirectory\foo.txt) of a file or directory where the dataitem originated, the “data state” attribute identifies a state of thedata file (e.g., closed, opened for read, opened for write, theaccumulated changes since a last checkpoint, or the like), and the“dirty” attribute identifies whether the item is “out-of-sync” with thedata in the DMS (which means that the file or directory in the host ismore up-to-date than the corresponding file or directory in DMS). In thelatter case, upward resynchronization with respect to DMS is required.For example, a file can be “dirty” if it is updated during a blackout,or if the delta events for the file fail to be applied at the DMS core.When a host server is rebooted, all items are assumed to be dirty. The“to be uploaded” attribute means that the item is not yet uploaded butneeds to be, the “to be recovered” attribute means that the item,although previously, uploaded, must be recovered, the “sent count”attribute refers to a number of message(s) that are forwarded to the DMShost during the upload and/or upward resynchronization, and the “databitmap” attribute is used for virtual recovery of a large file. Inparticular, virtual recovery may involve the following process. A largefile is divided into blocks, and the bitmap is used to indicate if ablock is recovered or not. If a block has a value 0, it is notrecovered; if the block has a value 1, it is recovered. Preferably, thesystem recovers a large file in sequential block order, although this isnot a requirement. In the event an application request arrives for adata block that is not yet recovered, preferably the system moves in theblock from DMS immediately so that the application does not have to waitfor it.

Raw events are available on the event queue 806, as described above. Aset of illustrative events are shown in the drawing and they include, inthis example: Open (object ID), Write (object ID, data range), Write(object ID, data range), System upgrade (timestamp), Write (object ID,data range), Trigger (ID, data, timestamp), Network events, and so on.Of course, this list is merely for illustration purposes.

In another illustrated embodiment, the protected data source may be adatabase, in which case the sorted source tree may be a list of files orvolumes the database uses. In this embodiment, the sorting order may bein ascending order of the database transaction log, the binary tablefiles or volumes, and the configuration files or volumes. If avolume-based database is to be protected, each volume can be treatedlike a file.

As will be described, a cursor 808 is set at the beginning of the sortedsource tree 804 and is incremented. Typically, events that occur “above”the cursor are processed immediately by the event processor logic 802and sent to the DMS node. Events that occur at or below the cursortypically may be subject to further processing, as will be described.Referring now to FIGS. 9-13, the operation of the event processor(during the initial upload and upward-resynchronization states) isdescribed for an illustrative embodiment in more detail. These processflows are not meant to be taken by way of limitation.

As illustrated in FIG. 9 (and with cross-reference to the FSM of FIG.7), in an illustrated embodiment there are three (3) possible initialentry points (corresponding to the incidents described above) withrespect to the upload and upward-resync states: begin data protection,step 902, rebooted, step 904, and reconnected 906. Step 902 is enteredwhen the finite state machine receives an incident that initiates thedata protection cycle. At step 908, the mode is set to upload, whichindicates the upload state has been entered. If the process is enteredat step 904, the mode is set at step 910 to resync. If the process isentered at step 906, the mode is set at step 912 to prior mode, whichrepresents a mode before the network disconnection (i.e., prior toblackout). Thus, the “mode” is synonymous with the “state” as that termhas been described above with respect to the finite state machine. Inthe upload process path, the process flow continues at step 914, wherethe event processor creates the sorted source tree and sets the cursorto the beginning of that tree. At step 914, the event processor alsosets the “to be uploaded” flag on all data items. The process thencontinues at step 916, which is also reached through step 915 in theresync process path. In particular, at step 915, the event processorcreates the sorted source tree, sets the cursor to point to thebeginning of the tree, and sets the “dirty” flag on all data items. Step916 is also reached from step 912, as indicated. At step 916, the eventprocessor configures the I/O filter, the application module, and/or thedatabase module to begin filtering events, as has been described above.The process flow then continues at step 918, during which the eventprocessor self posts an internal event if the associated event queue isempty. At step 920, the event processor removes an event from the eventqueue. A determination is then made at step 922 to test whether theevent is an internal event, an I/O event, an NSAD (network, system,application or database) event, or an XDMP event. FIG. 10 illustratesthe processing if the event is an internal event. This is step 1000.FIG. 11 illustrates the processing if the event is an input/outputevent. This is step 1100. FIG. 12 illustrates the processing if theevent is a network, system, application or database event. This is step1200. Finally, FIG. 13 illustrates the processing if the event is anXDMP event. This is step 1300. After the event is processed, the routinereturns to step 918, and the iteration continues.

FIG. 10 illustrates the processing for an internal event. The routinebegins at step 1002. At step 1004, the event processor locates thesorted source tree item that is at the cursor. A test is then run atstep 1006 to determine whether the “to be uploaded” flag is set. If yes,the routine branches to step 1008, where the event processor obtains thenecessary data of the item on the sorted source tree at the cursorposition. Continuing down this processing path, at step 1010, the eventprocessor generates a message, associates (e.g., bundles) the data withthe message, forwards that message (which now includes the data) to theXDMP protocol driver (for delivery to the DMS core), and increments thesent count. At step 1012, the event processor clears the “to beuploaded” flag on the sorted source tree for this particular entry,after which the event processor continues at step 1018 by moving thecursor to the next item in the sorted source tree. Alternatively, whenthe result of the test at step 1006 indicates that the “to be uploaded”flag is not set, the routine branches to step 1014 to determine whetherthe item is dirty. If not, the routine branches to step 1018, asillustrated. If the result of the test at step 1014 indicates that theitem is dirty, the routine branches to step 1016. At this step, theevent processor makes a request to a DMS core to retrieve remoteinformation to enable it to perform a comparative resynchronization,increments the sent count, and forwards the message to the XDMP protocoldriver (for delivery to the DMS core). Control then continues at step1018, as has been described. After step 1018, a test is performed atstep 1020 to determine whether the sorted source tree has beencompletely parsed. If yes, the routine branches to step 1022 to beginthe regular backup state. If, however, the result of the test at step1020 indicates that the sorted source tree is not yet parsed, theroutine returns to step 918 in FIG. 9.

FIG. 11 illustrates the processing for an input/output (I/O) event. Theroutine begins at step 1102 to test whether the event in questionaffects the sorted source tree. The events that might affect the sortedsource tree are events such as addition or deletion of data objects. Ifsuch an event is received, the routine branches to step 1104, duringwhich the event processor adjusts the sorted source tree and the cursoraccordingly. Control then returns to step 1106, which step is alsoreached when the outcome of the test at step 1102 is negative. At step1106, the event processor locates the target object in the sorted sourcetree. At step 1108, a test is performed to determine whether the targetobject is above the cursor. If not, the routine continues at step 1110to capture the relevant information of the event into a data state ofthe object item in the sorted source tree. Thus, e.g., if the protecteddata source is a file system the relevant information might be a “fileopen.” At step 1110, the event processor also drops the event. Theprocess flow then continues at step 1126. Alternatively, in the eventthe result of the test at step 1108 indicates that the target object isabove the cursor position on the sorted source tree, the process flowbranches to step 1112. At this step, a test is performed to determinewhether the item is dirty. If so, the event processor performs step1114, which means the resynchronization is in progress. Thus, the eventprocessor enters the event the relevant information of the event into adata state of the object item in the sorted source tree, drops theevent, and branches to step 1126. Thus, in a representative examplewhere changes since a last checkpoint are being accumulated, therelevant information might be the changed data. If, however, the outcomeof the test at step 1112 indicates that the item is not dirty, theroutine continues with step 1116 to process the event and enter therelevant information (e.g., a transaction record, attribute, or binarydata changes) into the data state. In this process flow path, theroutine then continues at step 1118, where a test is performed todetermine whether a consistent checkpoint has been reached. If not (anexample would be a file write on a regular file system), the routinebranches to step 1126. If, however, the result of the test at step 1118indicates a consistent checkpoint (e.g., a file “flushed” or “closed”for a file system, or a transaction checkpoint of a database), a furthertest is performed at step 1120 to determine whether the event processorneeds to create a delta value from the accumulated changes since thelast checkpoint in the data state. If not (e.g., because there isalready a transaction record for the event), the routine continues atstep 1122 to generate an event message, forward that message to the XDMPprotocol driver (for delivery to the DMS core), and then increment thesent count. If, however, the outcome of the test at step 1120 indicatesthat the event processor needs to create a delta value (e.g., togenerate deltas from the accumulated file changes upon a file “flushed”event), the routine continues at step 1124. During this step, the eventprocessor makes a request to retrieve remote information that isnecessary to generate the delta values, forwards the appropriate requestmessage to the XDMP protocol driver (for delivery to the DMS core),marks the item as dirty, and increments the sent count. Processingcontinues at step 1126 from either of step 1122 or step 1124. At step1126, a test is made to determine the mode. If the mode is upload orresync, the routine branches to step 918 in FIG. 9. This is step 1128.If the mode is regular backup, the routine enters the regular backupstate. This is step 1129. If the mode is recovering, the routine entersa recovery mode. This is step 1130.

FIG. 12 illustrates how the event processor handles network, system,application and/or database events. The routine begins at step 1202. Atstep 1204, a test is made to determine whether the event in question ismeaningful. If not, the routine branches to step 1208. If the event ismeaningful to the data source (e.g., a database checkpoint event), theroutine continues at step 1206. At this step, the event processorgenerates an event message, forwards that message to the XDMP protocoldriver and, if the event is associated with an item, the event processorincrements the sent count. The event may be bundled with relevant dataof the associated items. For example, if the event is a databasecheckpoint, deltas from the binary tables may be generated andassociated (e.g., bundled) with the XDMP message. Processing thencontinues at step 1208. At step 1208, a test is made to determine themode. If the mode is upload or resync, the branches to step 918 in FIG.9. This is step 1210. If the mode is regular backup, the routine entersthe regular backup state. This is step 1212. If the mode is recovering,the routine enters a recovery mode. This is step 1214.

FIG. 13 illustrates how the event processor handles given XDMP eventsand responses. As noted above, any convenient transport protocol may beused between the DMS host driver and DMS core. In this example, theroutine begins at step 1302. At step 1304, a test is performed todetermine the nature of the XDMP protocol event. If the event is a“connection failed,” the routine branches to step 1306, which indicatesthe blackout state. If the event is “recover,” the routine branches tostep 1308, which indicates that the event processor should enter therecovering-frame state. If the event is a “service terminate,” the eventprocessor exits the FSM, which is state 1312. If the event is a “requestfailed,” the routine continues at step 1314. At this step, the eventprocessor locates the item in the sorted source tree and marks the itemdirty (if a failure is associated with the item). The routine thencontinues in this process flow path with step 1318, with the eventprocessor making a request to retrieve information to enable it toperform a comparative resynchronization. During step 1318, the eventprocessor also forwards the message to the protocol driver. Finally, ifthe event is a “request succeeded,” the event processor continues atstep 1320 to locate the item on the sorted source tree and decrementsthe sent count. In this process path, the routine then continues at step1322, during which a test is performed to determine whether a successfulXDMP result or XDMP response with data has been received. If asuccessful XDMP result has been received, the process continues at step1324 by dropping the event. If, on the other hand, an XDMP response withdata has been received, the process branches to step 1326. At this step,the event processor compares the remote information with the local dataand generates the delta values. A test is then performed at step 1328 todetermine if a checkpoint has been reached. If not, the routine branchesto step 1332. If, however, a checkpoint has been reached, the processcontinues at step 1330. At this step, the event processor generates anXDMP event message, forwards the message to the XDMP protocol driver,increments the sent count, and clears the dirty flag. At step 1332,which is reached from one of the steps 1318, 1324, 1328 or 1330 asillustrated, a test is made to determine the mode. If the mode is uploador resynchronization, the routine branches to step 918 in FIG. 9. Thisis step 1334. If the mode is regular backup, the routine enters theregular backup state. This is step 1336. If the mode is recovering, theroutine enters a recovery mode. This is step 1338.

Further Details of the Recovering Frame and Recovery States

As noted above, once baseline data is uploaded to DMS, data history isstreamed into the DMS continuously as a real-time event journal. Anauthorized user can invoke a recovery from any of the regular backup orupward-resynchronization states when the host server is connected to theDMS core. (Alternatively, the data protection FSM can also allowrecovery to be invoked from the PBlackout state). In particular, a beginrecovery incident from either state drives the event processor to therecovering-frame state. During recovering-frame, the event processorreconstructs the sorted source tree that contains structural informationof the data being recovered. During this state, and depending on theunderlying data, the application may or may not be able to access thedata itself. Once the data structure is recovered, the event processortransitions to the recovering state. Before the data structure isrecovered, any blackout, reconnected or reboot incidents do not changethe event processor's state. During the recovering state, the eventprocessor recovers the actual data from DMS, preferably one data at atime. The event processor also recovers the data as application accessrequests continue to arrive, which enables the application to continuerunning during the recovering process. In addition, application updateevents continue to be streamed to DMS so that history continues to bemaintained with the event processor is recovering the data in the host.When data recovery is completed, the state of the data between the hostand the DMS is synchronized, and the corruption at the host is fixed.The event processor then returns to its regular back-up function.

The following provides additional details of an illustrated embodimentof the recovering frame and recovering functions.

FIG. 14 illustrates the event processor behavior during therecovering-frame state, which is reached from step 1308 in the routineof FIG. 13. At step 1402, the begin recovering-frame state is entered.At step 1403, the event processor configures the I/O filter to block allI/O events. At step 1404, the event processor then initializes thesorted source tree to an empty list and initializes a recovering cursorto a null position. The routine then continues at step 1405 with theevent processor issuing a protocol transport request to obtain forrecovery a root item, its properties, and its list of children. A rootitem may be any protected data object selected for recovery; typically,it is the data object whose recovery is a highest priority. In arepresentative example, the data object is a directory whose contents(subdirectories and files) have to be recovered. The structure for thedescendent elements (of the children) do not need to be fully recoveredduring this phase. As another example, the data object may be an onlinedatabase log file that must be recovered before any associated binarydata files.

As illustrated, the recovering-frame state can also be entered during areboot. This is step 1406. In this processing path, the event processoralso configures the I/O filter to block all I/O events, which is step1407. At step 1408, the event processor finds a next “tobeRecovered”frame item below the recovering cursor and moves the cursor down to thisposition. In step 1408, like step 1405, the event processor also issuesa transport protocol request to get the item properties and its list ofchildren. The event processor also increments an XDMP sent count duringthis step. Control then moves to step 1410, which is also reachedfollowing step 1405. At step 1410, the event processor de-queues anevent from the raw event queue. At step 1412, a test is performed todetermine whether the event processor has the event. If not, the routinecycles at step 1414. If the event processor has the event, a test isperformed at step 1416 to determine the transport protocol event type.If the event is an XDMP connection failure, the routine branches back tostep 1414. If the event is an XDMP connection resume, the routinebranches to step 1408. If the event is an XDMP service terminate event,the routine branches to step 1420 and exits. If the event is an XDMPrequest failed event, the event processor cannot recover the data; thus,an alert is issued at step 1422 and the routine exits at step 1424. Ifthe result of the test at step 1416 indicates an XDMP data event, theroutine continues at step 1426. At this step, the event processorcreates entries in the sorted source tree if necessary. It also placesthe property and data values into the target item in the sorted sourcetree, and updates the “tobeRecovered” frame item (as either arrived orstill awaiting data, as the case may be). During step 1426, the eventprocessor decrements the XDMP sent count and if places the recoveringcursor at the top of the sorted source tree if the item is the firstitem in the tree. Following step 1426, the routine branches to step 1428to test whether the frame has been fully recovered. If not, the routinebranches back to step 1408. If the frame is fully recovered, the routineends at step 1430. This places the event processor in the recoveringstate, which is illustrated in FIG. 15.

The recovering state begins at step 1502. At step 1504, the eventprocessor turns on the I/O filter and begins capturing read requests. Atstep 1506, the event processor sets the recovering cursor at a first“tobeRecovered” item on the sorted source tree. The routine thencontinues at step 1507 with the event processor issuing an XDMP requestto the download the data (or appropriate delta values) of the item towhich the recovering cursor points. Some at the recovering host data maybe completely missing or partially corrupted. For bandwidth efficiency,preferably the recovering process checks at step 1507 to determine ifthe recovering data exists in the local storage. If so, the recoveringprocess takes the local data to generate checksums, which the DMS thencan use to generate delta string to apply to the local data if thatlocal data is corrupted. This process is sometimes referred to herein asdownward resynchronization. If recovering data does not exist in thelocal storage, the entire data is requested at step 1507; this includesrecovering a container object (such as a directory whose children maynot be fully recovered) into the sorted source tree. The routine thencontinues with step 1508 with the event processor de-queueing an eventfrom the raw event queue. A test is then performed at step 1510 todetermine whether the event processor has the event. If not, the routinecycles at step 1512. If the event processor has the event, however, theroutine continues at step 1514 to determine the event type. If the eventtype is an XDMP event, the routine branches to step 1516, which directsthe event processor to handle the XDMP event during the recovering mode.This function is described below in FIG. 17. If the event is an NSAD(network, system, application or database) event, the routine returns tothe processing in FIG. 12, which has been described. This is steps 1518.If the event is an I/O event, the routine branches to step 1520, whichdirects the event processor to handle the I/O event during therecovering mode. This function is now described in FIG. 16.

The routine begins at step 1602. At step 1604, the event processorlocates the item on the sorted source tree. A test is then performed atstep 1606 to determine whether the item is an I/O read request. If not,the routines branches to step 1608. This returns control back to theroutine of FIG. 9. If, however, the test performed at step 1606indicates that the item is a read request, the routine continues at step1610 to test whether the structure of the item is not yet recovered intothe sorted source tree, or if the actual data of an existing item in thesorted source tree is to be recovered. If not (e.g., because the item isalready recovered), the routine branches to steps 1612 and drops theevent. If, however, the item is to be recovered, the routine continuesat step 1614. At this step, the event processor blocks the request,issues an XDMP request to DMS to recover the data for the item, andincrements an XDMP sent count. The type of request to recover the datafor the item depends on whether the recovering data exists in theprimary storage. A data object may exist during recovery if the objectis corrupted. If the object exists, checksums are computed and onlydeltas from DMS are requested; otherwise, the entire data is requested.The routine then ends at step 1616, with control then returning back tostep 1508 in FIG. 15 (which enables the event processor to get the nextevent from the raw event queue).

FIG. 17 illustrates how the event processor handles XDMP events duringthe recovering mode. As noted above, this routine is reached from step1516 in FIG. 15. The routine begins at step 1702. At step 1704, a testis performed to determine the XDMP event type. If the event is an XDMPconnection failure, the routine branches to step 1706. During this step,the event processor configures the I/O filter to block all I/O events.If the event is an XDMP connection resumed, the routine branches tosteps 1708. At this step, the event processor turns on the I/O filterand begins capturing read events. If the event is an XDMP serviceterminate, the routine branches to step 1710 and exits. If the event isan XDMP request failure, the routine branches to step 1712. At thisstep, the event processor locates the target item in the sorted sourcetree and decrements the XDMP sent count. After step 1712, in handlingthe XDMP request failure, the event processor performs a test at step1714 to determine if the failed request is a recovery request; if theresult of the test is positive, the routine branches to step 1716 tosend an alert, after which the routine exits. If, however, the outcomeof the test at step 1714 is negative, which indicates a backup failure,the event processor continues at step 1718. At this step, the eventprocessor marks the item as dirty and issues an XDMP request to retrieveremote information so that a comparative resynchronization can beperformed. The event processor also increments the XDMP sent count.After each of steps 1706, 1708 or 1718, as the case may be, the routineterminates and returns to step 1507 in FIG. 15.

If the XDMP event type is a response, the event processor enters step1720. At this step, the event processor locates the target item in thesorted source tree and decrements the XDMP sent count. The eventprocessor then tests at step 1722 to determine whether the recoveringitem has been modified during the process of requesting data from theDMS. If so, the routine branches to step 1724. At this step, if therecovering data is a container object (such as directory), the eventprocessor add its children to the sorted source tree, and the eventprocessor recovers the data back to primary storage, unblocks the “readrequest,” and, upon completion of the recovery, clears the“tobeRecovered” flag in the sorted source tree. After step 1724, theroutine terminates, which is step 1728. At this step, the recoverycursor is moved to the next item. As previously described, this returnscontrol back to step 1507 in FIG. 15. If, however, the outcome of thetest at step 1722 is negative, the routine branches to step 1726. Atthis step, the event processor verifies that the item is dirty and usesthe remote information to compare with the local data to generateappropriate delta (difference) data. This means that the host data wasmodified; therefore, a backup message with the most recent data must besent to the DMS. At step 1726, the event processor generates an XDMPmessage and forwards that message to the XDMP protocol driver. Afterincrementing the XDMP sent count, the routine terminates and returns tostep 1507 in FIG. 15, as previously described.

Summarizing, once a baseline data is uploaded to the DMS, data historyis streamed into the DMS continuously, preferably as a real time eventjournal. An authorized user can invoke a recovery at any of the stateswhen the host server is connected to the DMS core, namely, during the“Regular-backup” and “Upward-resync” states. If the authorized user doesso, a “Begin-recovery” incident occurs, which drives the event processorstate to the recovering-frame state illustrated in FIGS. 14-15. Duringthe recovering-frame state, the event processor reconstructs the sortedsource tree either in full or partially, which (as noted above) containsstructural information of the data to be recovered. During this state,and depending on the underlying data, the application may or may not beable to access the data. Once the data structure is partially or fullyrecovered, a “Done-Recovering-Frame” incident is generated, which thentransitions the event processor to the recovering state illustrated inFIGS. 16-17. During the recovering state, the event processor recoversthe actual data and additionally some data structure (if such structureis not fully recovered in the “Recovering-Frame state”) from the DMS,preferably a data point at a time. It also recovers data as anapplication access request arrives to enable the application tocontinuing running. During the recovering state, application updateevents are streamed to the DMS so that history is continued to bemaintained, even as the event processor is recovering the data in thehost. When data recovery is completed, once again the state of the data(at both ends of the stream) is synchronized, and the corruption at thehost is fixed. The event processor then transitions back to a regularback-up state.

Variants

While the present invention has been described with respect to certainembodiments, such embodiments are not meant to be limiting. Thus, forexample, the on-demand recovery techniques of the present invention arenot limited to recovering data to a host whose data is incorrect orcorrupt. The techniques may also be applied to recover data to a newhost, i.e., a host without any data in the first instance. In addition,while the “upward resynchronization” function described above is oneillustrative embodiment, the present invention also envisions on-demandrecovery in the context of a “downward resynchronization” (or “downwardresync”) operation, i.e., when there is existing data on the host (whichmay be incorrect or corrupt) and it is desired to send deltas (i.e.,differences) from the DMS to the host to facilitate recovery. Downwardresync is useful as an optimization when a host is not empty and the DMScan send (to the host) differences to recover the host data instead ofdownloading the entire data set. During downward resync, the protectedapplication can still access and update the data in a real-timecontinuous manner (by streaming of the application-aware events to DMSas has been described). Thus, the present invention envisions virtualon-demand recovery to an empty host or a host whose data is corrupted orincorrect, and such recovery can occur by having DMS send the entiredata set or differences, as the case may be.

In addition, it may be desirable to simultaneously recover data andstructure during the recovering state in the event the structure is notfully recovered during the recovering-frame state.

DMS provides significant advantages over the prior art. Unlike aconventional data protection system the data protection service providedby DMS is automated, real-time, and continuous, and it exhibits no orsubstantially no downtime. At the same time, and unlike conventionaldata protections techniques and systems, the DMS guarantees recoveryconsistency through its ability to identify consistency eventsassociated with an application and data. This is because DMS is keepingtrack of the real-time data history, and because preferably the state ofthe most current data in a DMS region, cluster or node (as the case maybe) must match the state of the data in the original host server at alltimes. In contrast, data recovery on a conventional data protectionsystem means shutting down a host server, selecting a version of thedata history, copying the data history back to the host server, and thenturning on the host server. All of these steps are manually driven. Insuch techniques, the recovered data may not be consistent and theintegrity of the data is not guaranteed; typically, more manual workthen is required to perform data integrity and consistency verification.After a period of time following recovery, the conventional dataprotection system then performs a backup on the changed data. In thepresent invention, as has been described above, the otherwise separateprocesses (initial data upload, continuous backup, blackout and dataresynchronization, and recovery) are simply phases of the overall dataprotection cycle. This is highly advantageous, and it is enabled becauseDMS keeps a continuous data history. Stated another way, there is no gapin the data. The data protection cycle described above preferably loopsaround indefinitely until, for example, a user terminates the service. Agiven data protection phase (the state) changes as the state of the dataand the environment change (the incident). Preferably, as has beendescribed, all of the phases (states) are interconnected to form afinite state machine that provides the data protection service.

The data protection service provided by the DMS has no effectivedowntime because the data upload, data resynchronization, data recoveryand data backup are simply integrated phases of a data protection cycle.At the same time, DMS provides on-demand data paging during recovery sothat data can be accessed and modified simultaneously before it is fullyrecovered. There is no application downtime.

The present invention has numerous advantages over the prior art such astape backup, scheduled disk-based backup, volume replication, storagesnapshots, application replication, remote replication, and manualrecovery. Indeed, existing fragmented approaches are complex, resourceinefficient, expensive to operate, and often unreliable. From anarchitectural standpoint, they are piecemeal tools that are designed toaddress ad hoc data management problems; such tools are not capable ofcovering all failures, they are difficult to integrate, and they requireintensive manual operation. Therefore, these prior art solutions are notwell-suited to scaling to support heterogeneous, enterprise-wide datamanagement. The present invention overcomes these and other problems ofthe prior art by providing real-time data management services. As hasbeen described, the invention transparently and efficiently captures thereal-time continuous history of all or substantially all transactionsand data changes in the enterprise. The solution operates over local andwide area IP networks to form a coherent data management, protection andrecovery infrastructure. It eliminates data loss, reduces downtime, andensures application consistent recovery to any point in time. These andother advantages are provided through the use of an application awareI/O driver that captures and outputs a continuous data stream—in theform of an event journal—to other data management nodes in the system.

As one of ordinary skill in the art will appreciate, the presentinvention addresses enterprise data protection and data managementproblems by continuously protecting all data changes and transactions inreal time across local and wide area networks. Preferably, and asillustrated in FIG. 1, the method and system of the invention takeadvantage of inexpensive, commodity processors to efficiently parallelprocess and route application-aware data changes between applicationsand low cost secondary storage.

While the present invention has been described in the context of amethod or process, the present invention also relates to apparatus forperforming the operations herein. In an illustrated embodiment, theapparatus is implemented as a processor and associated program code thatimplements a finite state machine with a plurality of states and toeffect transitions between the states. As described above, thisapparatus may be specially constructed for the required purposes, or itmay comprise a general purpose computer selectively activated orreconfigured by a computer program stored in the computer. Such acomputer program may be stored in a computer readable storage medium,such as, but is not limited to, any type of disk including opticaldisks, CD-ROMs, and magnetic-optical disks, read-only memories (ROMs),random access memories (RAMs), magnetic or optical cards, or any type ofmedia suitable for storing electronic instructions, and each coupled toa computer system bus.

While the above written description also describes a particular order ofoperations performed by certain embodiments of the invention, it shouldbe understood that such order is exemplary, as alternative embodimentsmay perform the operations in a different order, combine certainoperations, overlap certain operations, or the like. References in thespecification to a given embodiment indicate that the embodimentdescribed may include a particular feature, structure, orcharacteristic, but every embodiment may not necessarily include theparticular feature, structure, or characteristic.

While the above has been described in the context of an “upload” betweena local data store and a remote data store, this nomenclature should notbe construed as limiting. Generalizing, the method and system involvesmonitoring events (e.g., as a given application interfaces to a localdata store in a first processing environment), and then transferring toa second data store (remote from the first processing environment) acontinuous, application-aware data stream while maintaining execution ofthe given application in the first processing environment. This enablesthe transfer of a baseline version. In addition, as theapplication-aware data stream is being transferred (e.g., by uploading),one or more application update events can be processed into the datastream.

Having described my invention, what I now claim is as follows.
 1. Amethod of data recovery as a data protection service is being providedin a first processing environment, where, in connection with the dataprotection service, data has been stored in a data store remote from thefirst processing environment, the method comprising: initiating a datarecovery operation upon a determination that given data in the firstprocessing environment needs to be recovered because it is missing,incorrect or corrupted; recovering the given data to a formerpoint-in-time state as reflected in the data store, wherein the recoverycomprises: presenting a structure of the given data to an applicationassociated with a data source so that, from a point-of-view of theapplication, the data source is recovered prior to fully synchronizingthe data source; and synchronizing the data source to the structure ofthe given data; and enabling the application to continue accessing orupdating the given data during the recovery.
 2. The method as describedin claim 1 wherein the application continues to access or update thegiven data by generating a continuous, application-aware data stream andtransferring the data stream to the data store.
 3. The method asdescribed in claim 1 wherein presenting the structure of the given datagenerates, from information in the data store, a sorted data list thatis used to generate the structure in the data source.
 4. The method asdescribed in claim 3 further comprising filtering access requests duringpresenting the structure of the given data.
 5. The method as describedin claim 4 wherein READ requests are filtered synchronously.
 6. Themethod as described in claim 5 wherein a given READ request is servedfrom the data source.
 7. The method as described in claim 5 wherein agiven READ request is failed.
 8. The method as described in claim 3further comprising filtering access requests as the given data issynchronized to its former point-in-time.
 9. The method as described inclaim 4 wherein WRITE requests are failed.
 10. The method as describedin claim 8 further comprising: using the sorted data list to determinewhether an access request is for data that has not been recovered; andif the access request is for data that has not been recovered, promptlyrecovering the data requested.
 11. The method as described in claim 10further comprising marking, in the sorted data list, a given data itemas recovered if an application-aware data stream provided to the datastore comprises information associated with the given data item.
 12. Themethod as described in claim 1 further comprising the re-initiatingprotection of the data source following completion of the recoveringstate.
 13. A method of recovering a data source in a host at a firstlocation with associated data history at a second location remote fromthe first location, comprising: upon initiation of a data recovery ofthe data source or a subset thereof, adjusting a current state of thedata source at the second location by moving a past state to the currentstate; and retrieving a most current state from the second location;recovering the data source or the subset thereof using the most currentstate retrieved from the second location, wherein the data source or thesubset thereof remains accessible to an application in the host duringthe recovery; and continuing collection of the data history at thesecond location as the data source or the subset thereof is recoveredand following such recovery.
 14. An apparatus for use in providing adata recovery service to a data source in a host, comprising: aprocessor; and code executable by the processor to continuously generateand forward to a remote location a data history; and code executable bythe processor and responsive to initiation of a data recovery operationfor the data source or a subset thereof (a) to retrieve from the remotelocation a former point-in-time state of the data source or the subsetthereof, and (b) to recover the data source or the subset thereof to theformer point-in-time state, wherein the recovery comprises: presenting astructure of given data to an application associated with the datasource so that, from a point-of-view of the application, the data sourceis recovered prior to fully synchronizing the data source; synchronizingthe data source to the structure of the given data; and enabling theapplication to continue accessing or updating the given data during therecovery.
 15. The apparatus as described in claim 14 further comprisingcode executable by the processor to recover a structure of the datasource or the subset.
 16. The apparatus as described in claim 14 furthercomprising an interface at which a recovery command is entered toinitiate the data recovery operation.